home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 13 < prev    next >
Internet Message Format  |  1994-08-27  |  3KB
  1. Date: Mon, 30 May 1994 02:49:02 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: Re: Colour.
  4. To: gem-list@world.std.com
  5. In-Reply-To: <9405300406.AA21718@uqcspe.cs.uq.oz.au>
  6. Message-Id: <Pine.3.87.9405300202.A15807-0100000@undergrad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11. [Below, I state only opinions...]
  12.  
  13.  
  14. On Mon, 30 May 1994, Warwick Allison wrote:
  15.  
  16. > 
  17. > As I see it, the major issues with colour palette handling by GEM programs are:
  18. > 
  19. >     - The standard 16 colours
  20. >         - They're different under MultiTOS (right?)
  21. >         - When should a program desire to change them?
  22. When it's window is topped.
  23. >         - When should a user desire to change them?
  24. Expound on this questions please.
  25. > 
  26. >     - Sharing colours
  27. >         - No point each program allocating its own Purple
  28. >         - When colours must be changed, it would be nice for
  29. >            the actual palette change to be minimized (eg. purple
  30. >            changes to dark purple, not green)
  31. Are you sure programmers are going to want to put forth that effort?  
  32. It's much easier to just stick together your palette.  How about someone 
  33. write a library routine that, given a new palette, sorts them with respect
  34. to the palette in place?
  35.  
  36. >     - True Colour emulations
  37. >         - Some programs use a 5x5x5 or 6x6x6 colourspace, and
  38. >            these should all be the same space.
  39. > 
  40. >     - When to change palettes
  41. >         - When window is topped?
  42. Only this one.
  43. >         - When window is touched in any way?
  44. In most cases, this would top the window.  Under MultiTOS or others, 
  45. where you can use the gadgets without topping the window, the palette 
  46. should NOT be changed to the one for that window... how would you know 
  47. when to change it back?
  48. >         - When mouse enters window?
  49. Too difficult... requires that something watch the mouse pointer.
  50. > 
  51. > 
  52. > Some time ago, I posted a draft proposal for this, but it was probably
  53. > a too-complex proposal, and so I would like to hear of any conventions
  54. > currently in use.
  55. > 
  56. > As a first point of discussion, what are the pros and cons of a simple
  57. > system like this:
  58. > 
  59. >     Each application sets the palette whenever one of its windows
  60. >     is topped.  They use colours above 15 if available.
  61. > 
  62. > --
  63. > Warwick
  64. > 
  65. Your proposal is sound, however, since not all apps will follow this, and 
  66. the WM_TOPPED signal is broadcast globally, perhaps apps should set the 
  67. palette BACK to what it was before when it's window is untopped?  The 
  68. only problem with that is if the newly topped app sets a palette before 
  69. the old one resets the palette... this would cause a conflict.
  70.  
  71. For colors, an app should scan all available colors and see what it can 
  72. match to.  When changing the palette, it should favor using those above 15.
  73.  
  74. Since GEM is too free about this, this one is going to be tough for us to 
  75. work out, especially since no-one before will have followed these rules, 
  76. yet we'll have to tollerate their apps.
  77.  
  78.  
  79.